Git Pie é um guia completo sobre Git e controle de versão, criado especialmente para desenvolvedores brasileiros. Nossa proposta é ensinar Git de forma clara, objetiva e com uma pitada de humor.
Próximo Passo Recomendado: Comece pelos Conceitos Básicos (Conceitos Básicos do Git) para construir uma base sólida.
Intro - Aprenda sobre VCS
American pie
Nota do Autor
Olá pessoas, nesse texto irei falar sobre VCS (Sistema de Versionamento de Código, sigla em inglês) ou melhor, como o tema é mais conhecido - falarei sobre Git.
O que você vai aprender aqui?
Stifler teaching
"Deixa que o Stifler te explica essa parada!"
Nesse guia você vai aprender:
Como não perder código igual perdeu aquela crush do ensino médio
Como trabalhar em equipe sem querer matar seus colegas
Como versionar código igual um profissional (e não usando projeto-final-v3-agora-vai-mesmo.zip)
Como usar Git e não passar vergonha nas entrevistas de emprego
Roadmap de Aprendizado
American pie road
A estrada do conhecimento é longa, mas é divertida!
Mapa Mental dos Conceitos
Para você que gosta de ver o todo antes de se perder nos detalhes (tipo quando você olha o cardápio inteiro antes de pedir)
Por que você deveria aprender Git?
Stifler convinced
"Confia no pai que essa é boa!"
Imagina só:
Você tá lá, codando tranquilo
Fez alterações MASSAS no projeto
Aí seu PC resolve dar aquela travada marota
E... BOOM! 💥 Perdeu tudo!
Ou pior:
Você e seu amigo precisam trabalhar no mesmo projeto
Nota: Se em algum momento você se perder, não se preocupe! É normal, todo mundo já passou por isso. Até o Stifler já perdeu código antes de aprender Git!
Conceitos Básicos de Versionamento
Versionamento de Código
Versionamento é um conceito muito simples e usado no dia a dia de forma que nem percebemos. Por exemplo: Estamos em um projeto onde temos dois desenvolvedores:
Stifler
Stifler dude no
Jim
Jim american pie
Esses dois desenvolvedores estão fazendo o "Milfs Go" uma especie revolucionaria e inovadora, além do tempo sendo um app para acharem a "milfs".
Aqui está uma milf para aqueles não habituados com o termo:
American pie good stuff
Controle de Versão
Versionamento é o ato de manipular versões, agora o Controle de Versão é um sistema que vai registrar as mudanças tanto num arquivo como em um projeto gigante ao longo do tempo.
Tipos de Controle de Versão
Local
Mantém as versões apenas na sua máquina
Simples mas limitado
Exemplo: copiar e renomear arquivos
Centralizado
Um servidor central guarda todas as versões
Todos se conectam a este servidor
Exemplo: SVN
Distribuído
Cada desenvolvedor tem uma cópia completa
Trabalho offline possível
Exemplo: Git
Importância
Talvez agora você levante uma questão de o porque aprender "este trem" - como diria um amigo mineiro. Logo, a resposta é simples: esse tipo de ferramenta é essencial para o desenvolvimento já que nos entrega um poder de não somente trabalhar em conjunto de forma assíncrona e sem medo de acabar perdendo o que já foi feito.
Benefícios do Controle de Versão
Histórico Completo
Rastreamento de todas as mudanças
Quem fez o quê e quando
Possibilidade de reverter alterações
Trabalho em Equipe
Múltiplos desenvolvedores
Desenvolvimento paralelo
Resolução de conflitos
Backup
Cópia segura do código
Recuperação de desastres
Múltiplas cópias distribuídas
Fluxo Básico
Modificação
Alteração nos arquivos
Criação de novos arquivos
Exclusão de arquivos
Stage
Preparação das mudanças
Seleção do que será versionado
Organização das alterações
Commit
Confirmação das mudanças
Criação do ponto de versão
Registro no histórico
Boas Práticas
Commits Frequentes
Mudanças pequenas e focadas
Mais fácil de entender e reverter
Melhor rastreabilidade
Mensagens Claras
Descreva o que foi alterado
Seja conciso mas informativo
Use tempo verbal consistente
Branches Organizados
Separe features em branches
Mantenha o main/master estável
Merge apenas código testado
Próximos Passos
Agora que você entende os conceitos básicos, está pronto para:
Dica: Mantenha este capítulo como referência! Os conceitos básicos são fundamentais para entender as operações mais avançadas que virão pela frente.
História do Controle de Versão
A Evolução do Versionamento
Como passamos de backups manuais para sistemas distribuídos modernos
A Linha do Tempo Detalhada
Anos 70-80: A Pré-História do Código
SCCS (1972)
Criador: Marc Rochkind na Bell Labs
Inovações:
Primeiro sistema real de controle de versão
Introduziu o conceito de deltas reversos
Arquivos de histórico com extensão ,v
Limitações:
Apenas um arquivo por vez
Sem networking
Unix only
SCCS
|-- arquivo,v
|-- histórico
`-- locks
RCS (1982)
Criador: Walter F. Tichy
Melhorias:
Sistema de branching primitivo
Melhor performance
Formato de arquivo mais eficiente
Comandos mais intuitivos
Ainda usado para:
Controle de configuração
Documentação
Projetos simples
Anos 90: A Revolução Centralizada
CVS (1990)
Criador: Dick Grune
Revolucionou com:
Desenvolvimento paralelo
Operações em rede
Repositórios compartilhados
Tags e branches
Problemas famosos:
Commits não atômicos
Renomeação de arquivos complicada
Bugs de merge
CVS Server
/ | \
Client Client Client
SVN (2000)
Criador: CollabNet
Avanços:
Commits verdadeiramente atômicos
Melhor handling de binários
Renomeação e move de arquivos
Metadados versionados
Ainda popular em:
Empresas tradicionais
Projetos com muitos binários
Sistemas legados
Anos 2000+: A Era Distribuída
Git (2005)
Criador: Linus Torvalds
Motivação:
BitKeeper removeu licença gratuita do kernel Linux
Necessidade de sistema rápido e distribuído
Inovações:
Modelo distribuído
Branching super leve
Staging area
Integridade criptográfica
Por que dominou:
Performance excepcional
GitHub e social coding
Flexibilidade extrema
Workflow distribuído
Git Flow
main
|\
| feature
|/
|\
| hotfix
|/
Mercurial (2005)
Criador: Matt Mackall
Diferencias:
Interface mais amigável
Curva de aprendizado menor
Extensibilidade via Python
Usado por:
Facebook
Mozilla
Google (parcialmente)
Anos 2010+: A Era Social
GitHub (2008)
Transformou Git em plataforma social
Pull Requests revolucionaram code review
Actions trouxeram CI/CD integrado
Copilot iniciou era da IA no código
GitLab (2011)
Alternativa self-hosted ao GitHub
CI/CD integrado desde o início
DevOps como plataforma
Lições da História
O que Aprendemos
Evolução Constante
De single-file para repositórios completos
De local para distribuído
De linha de comando para interfaces gráficas
Padrões que Permaneceram
Importância do histórico
Necessidade de branches
Valor da colaboração
Tendências Futuras
Integração com IA
Automação crescente
Colaboração em tempo real
Conclusão
A história dos sistemas de controle de versão é uma jornada fascinante de evolução tecnológica. De simples backups numerados até sistemas distribuídos com IA, cada era trouxe suas inovações e aprendizados. Como diria a mãe do Stifler: "As festas podem mudar, mas a diversão continua a mesma!"
E lembre-se: conhecer a história nos ajuda a entender melhor as ferramentas que usamos hoje e apreciar como chegamos até aqui. Afinal, se hoje podemos fazer um git push sem pensar duas vezes, é porque muita gente quebrou a cabeça com SCCS e CVS antes!
Tipos de Sistemas de Controle de Versão
Sistemas Locais
Imagine que o Stifler está tentando escrever a "bíblia das milfs" em seu computador. Toda vez que ele faz uma alteração importante, cria uma nova pasta chamada "versão_final", "versão_final_2", "versão_final_2_agora_vai"... Isso é basicamente um sistema local de controle de versão!
Características dos Sistemas Locais
Simplicidade: Tão simples quanto renomear arquivos
Independência: Funciona offline, como o Stifler escrevendo sozinho em casa
Limitações: Se o HD queimar, tchau bíblia das milfs
Risco: Um problema no computador e todo o histórico se perde
Version control system sistema local
Diagrama de um sistema local (ou como Stifler organiza seus arquivos)
Analogia da Festa
É como fazer uma festa sozinho. Você tem todo o controle, mas:
Ninguém mais participa
Se sua casa pegar fogo, acabou a festa
Você não pode estar em dois lugares ao mesmo tempo
Sistemas Centralizados
Agora imagine que Jim e Stifler decidem trabalhar juntos no "Milfs Go". Eles precisam de um lugar central para guardar o código - tipo a casa da mãe do Stifler (que ironicamente é uma milf).
Como Funciona
Um servidor central (a casa da mãe do Stifler)
Todos os desenvolvedores se conectam a ele
Precisa de internet para trabalhar
Desvantagens dos Sistemas Centralizados
Ponto único de falha: Se a mãe do Stifler sair de casa, ninguém trabalha
Dependência de rede: Sem internet, sem código
Performance: Lento como Stifler tentando resolver cálculo
Conflitos: Como Jim e Stifler brigando pelo mesmo arquivo
Version control system sistema compartilhado
Diagrama de um sistema centralizado (ou a casa da mãe do Stifler)
Analogia da Festa Centralizada
É como uma festa na casa da mãe do Stifler:
Todo mundo precisa ir até lá
Se a casa fechar, acabou a festa
Só dá para fazer as coisas se você estiver lá
Sistemas Distribuídos
Finalmente, temos o sistema que é tipo a internet das milfs - todo mundo tem uma cópia completa de tudo!
Por que é Melhor?
Trabalho offline: Como Stifler "estudando" em casa
Backup distribuído: Cada cópia é um backup completo
Performance: Rápido como Stifler correndo atrás de... você sabe
Flexibilidade: Múltiplos fluxos de trabalho possíveis
Analogia da Festa Distribuída
É como ter várias festas simultâneas:
Cada um pode ter sua própria festa
As festas podem se sincronizar
Se uma festa acabar, as outras continuam
Características Avançadas
Branches Distribuídos
Como diferentes capítulos do "Milfs Go"
Cada um trabalha no seu
Depois junta tudo
Colaboração
Pull requests (como pedir permissão para a mãe do Stifler)
Code review (Jim revisando as besteiras do Stifler)
Forks (fazer sua própria versão do "Milfs Go")
Tabela Comparativa Estilo American Pie
Característica
Local
Centralizado
Distribuído
Backup
Frágil como o ego do Stifler
Médio
Forte como a mãe do Stifler
Colaboração
Solo
Limitada
Total
Offline
Sim
Não
Sim
Complexidade
Fácil
Média
Complexa
Confiabilidade
Baixa
Média
Alta
Exemplos Históricos
Sistemas Locais (Anos 80)
RCS: O vovô dos sistemas de versão
SCCS: Ainda mais velho que a mãe do Stifler
Sistemas Centralizados (Anos 90-2000)
SVN: O pai dos sistemas centralizados
CVS: O tio que ninguém mais visita
Perforce: O primo rico
Sistemas Distribuídos (2005+)
Git: O rei da festa
Mercurial: O amigo legal que ninguém lembra
Bazaar: Aquele que tentou mas não vingou
Conclusão
Escolher um sistema de controle de versão é como escolher onde fazer a festa:
Na sua casa (Local)
Na casa da mãe do Stifler (Centralizado)
Em todas as casas ao mesmo tempo (Distribuído)
Stifler aprovando sistemas distribuídos
Nota Final
Lembre-se: assim como Stifler aprendeu a respeitar as milfs, você precisa respeitar seu sistema de controle de versão. Escolha sabiamente!
E viveram felizes para sempre com Git
Sistemas de Controle de Versão Local
Um sistema de controle de versão local é a primeira e mais básica forma de versionamento de código. Imagine como uma máquina do tempo pessoal para seu código, onde todas as mudanças são registradas e armazenadas localmente no seu computador.
Como Funciona na Prática
Analogia com um Álbum de Fotos
+------------------------+
| Seu Projeto |
| +-----------------+ |
| | Versão Atual | |
| +-----------------+ |
| | Versão Anterior | |
| +-----------------+ |
| | Versões Antigas | |
| +-----------------+ |
+------------------------+
+----------------+
| Projeto Local |
+----------------+
|
v
+----------------+
| Backup Externo |
+----------------+
|
v
+----------------+
| Cloud Storage |
+----------------+
3. Documentação
Comentários claros
Descrições de versão
Registro de mudanças
Notas de implementação
Sistemas de Controle de Versão Centralizado
Um sistema de controle de versão centralizado (CVCS) é como uma festa na casa da mãe do Stifler - todos precisam ir ao mesmo lugar para participar! Este sistema utiliza um servidor central que armazena todos os arquivos versionados e permite que múltiplos desenvolvedores colaborem no mesmo projeto.
Características Principais
1. Servidor Central
Repositório único e autoritativo
Controle de acesso centralizado
Backup centralizado
Administração simplificada
2. Clientes
Checkout de arquivos específicos
Histórico parcial
Dependência de conectividade
Workspace local limitado
A Casa da Mãe do Stifler
Como uma festa na casa da mãe do Stifler, todos precisam ir ao mesmo lugar para participar!
Sabe aquela rede social onde todo mundo tem sua própria cópia das fotos e vídeos? Pois é, um sistema distribuído é exatamente assim! Cada desenvolvedor tem uma cópia completa do projeto, como se cada um tivesse sua própria festa particular.
Por que é tipo uma Rede Social?
Todo Mundo tem Tudo
Imagine que o Stifler, o Jim e o Finch estão trabalhando juntos. Cada um tem uma cópia completa do projeto no seu computador. É como se cada um tivesse baixado todas as fotos e vídeos da festa - ninguém depende do celular dos outros pra ter acesso às memórias da noitada.
Trabalho Offline? Pode Sim!
Diferente do sistema centralizado (onde todo mundo depende da casa da mãe do Stifler), aqui cada um pode trabalhar no seu canto. O Jim pode codar mesmo quando sua internet cair, o Finch pode fazer alterações no ônibus, e o Stifler... bem, ele pode programar onde ele quiser (provavelmente enquanto procura milfs no Tinder).
Compartilhando as Novidades
Quando alguém quer mostrar seu trabalho, é só dar um "push" (tipo postar na rede social). E quando quer ver o que os outros fizeram? Dá um "pull" (como dar aquela stalkeada básica no feed dos amigos).
Local Operations
⚡️ SUPER RÁPIDO ⚡️
└── Commits
└── Branches
└── History
└── Diffs
Vantagens de Ter Sua Própria Festa
1. Independência Total
Faça commits sem precisar de internet
Crie branches experimentais sem medo
Trabalhe no seu ritmo
Teste coisas malucas sem ninguém saber
2. Backup em Todo Lugar
Lembra quando o Stifler perdeu todas as fotos da festa porque derrubou cerveja no computador? Com DVCS isso não seria um problema! Como todo mundo tem uma cópia completa, é praticamente impossível perder o código. É tipo ter backup até no backup do backup.
3. Performance Insana
Quase tudo é local, então é mais rápido que o Stifler correndo atrás de uma milf. Commits, branches, histórico - tudo acontece na velocidade da luz porque não precisa ficar perguntando pro servidor.
Como Funciona na Prática?
O Dia a Dia
Clone: Primeiro você clona o repositório - é tipo fazer o download da festa inteira
Trabalho Local: Faz suas alterações na sua cópia - como editar suas fotos antes de postar
Commit: Salva as alterações localmente - guardando suas edições no rascunho
Push: Envia para o repositório remoto - finalmente postando na rede social
Pull: Baixa alterações dos outros - atualizando seu feed
Quando Tem Treta
Às vezes duas pessoas mudam a mesma coisa - tipo o Stifler e o Jim editando a mesma foto. Isso gera um conflito, mas não é o fim do mundo:
O sistema avisa que tem conflito
Você decide qual versão manter (ou combina as duas)
Faz um novo commit com a resolução
Todo mundo fica feliz!
1. Flexibilidade Máxima
2. Colaboração Avançada
3. Segurança Reforçada
+-------------------+
| Repo Central |
+-------------------+
|||
+----------+
| Clones |
+----------+
| Backups |
+----------+
| História |
+----------+
Sistemas Populares
Workflows Populares
1. Feature Branch
Cada nova funcionalidade ganha sua própria branch. É como se cada nova ideia maluca do Stifler tivesse seu próprio espaço para não bagunçar a festa principal.
2. Gitflow
Um workflow mais estruturado, com branches específicas para desenvolvimento, features, releases e hotfixes. É tipo ter áreas VIP, pista de dança e bar separados na festa.
3. Trunk Based
Desenvolvimento direto na main com branches curtas. É como uma festa mais intimista, onde todo mundo fica no mesmo ambiente.
main
|
├── feature/quick
| └── merge rápido
|
├── feature/small
| └── merge rápido
|
└── atual
Toda IDE que se preze tem integração com Git. Use e abuse delas!
3. CLI Aprimorada
Personalize seu terminal para trabalhar melhor com Git. Aliases e prompts podem salvar seu dia!
Conclusão
DVCS é como ter uma festa particular que pode se conectar com outras festas quando quiser. Cada um tem seu espaço, suas regras, mas todo mundo pode compartilhar quando estiver pronto! É a democracia do código - todo mundo tem poder igual, ninguém depende de um servidor central, e a festa nunca para!
Comparando Sistemas de Controle de Versão
Vamos fazer uma análise profunda dos diferentes sistemas de controle de versão, usando analogias divertidas para entender melhor cada um. É como comparar diferentes tipos de festas - cada uma tem seu propósito e seu público!
Dica Pro: Comece pequeno, com um projeto piloto, antes de expandir para toda a organização!
Controle de Versão Baseado em Blockchain
O controle de versão baseado em blockchain é uma abordagem inovadora que combina os princípios de sistemas de controle de versão distribuídos com a tecnologia blockchain.
Conceitos Fundamentais
O que é Controle de Versão Blockchain?
Características Principais
Imutabilidade: Histórico permanente e inalterável
Descentralização: Sem servidor central
Transparência: Todas as alterações são rastreáveis
Criptografia: Segurança integrada
Consenso: Validação distribuída de alterações
Implementações
GitChain
Características do GitChain
Integração com Git existente
Smart contracts para validação
Tokens para governança
Prova de trabalho otimizada
Vantagens e Desvantagens
Vantagens
Histórico imutável
Auditoria garantida
Descentralização real
Propriedade verificável
Segurança criptográfica
Desvantagens
Casos de Uso
Ideal Para
Software crítico
Contratos inteligentes
Projetos regulamentados
Propriedade intelectual
Auditorias rigorosas
Exemplos Práticos
Ferramentas e Plataformas
Populares
CodeChain: Plataforma blockchain para código
VersionX: Sistema híbrido Git+Blockchain
BlockVCS: Controle de versão descentralizado
Integração
# Exemplo de uso com CodeChain
cchain init
cchain commit -m "feat: nova funcionalidade"
cchain validate
cchain push --network ethereum
Dica Pro: Comece com uma rede privada para experimentar antes de migrar para uma rede pública!
Fluxos de Trabalho em Versionamento
Modelos de Fluxo de Trabalho
Trunk-Based Development
Desenvolvimento direto na branch principal
Integração contínua frequente
Ideal para equipes pequenas e ágeis
Feature Branch Workflow
Branch separada para cada feature
Merge através de pull requests
Revisão de código facilitada
Gitflow
Branches específicas para features, releases e hotfixes
Estrutura mais rigorosa
Ideal para releases planejadas
Forking Workflow
Fork do repositório principal
Comum em projetos open source
Maior isolamento entre contribuições
Escolhendo um Workflow
Fatores a Considerar
Tamanho da equipe
Frequência de releases
Complexidade do projeto
Necessidades de QA
Exemplos Práticos
Boas Práticas
Commits frequentes e pequenos
Mensagens de commit claras
Code review regular
Testes antes do merge
Documentação atualizada
Ferramentas de Suporte
CI/CD pipelines
Code review platforms
Issue trackers
Automação de testes
Trunk-Based Development
Imagine uma festa onde todo mundo dança na mesma pista. É assim que funciona o Trunk-Based Development (TBD)!
Anatomia do TBD
Como Funciona?
Todo mundo trabalha direto na branch principal (trunk/main):
Regras do Jogo
1. Commits Pequenos e Frequentes
2. Testes Antes de Tudo
3. Feature Flags
Código novo entra escondido
Ativa quando estiver pronto
Como uma surpresa na festa!
Ciclo de Vida do Código
Fluxo de Trabalho Típico
Por Que Usar?
Vantagens
Integração contínua real
Menos conflitos
Deploy mais rápido
Todo mundo no mesmo ritmo
Desafios
Precisa de muita disciplina
Testes automatizados são obrigatórios
Feature flags para código incompleto
Na Prática
Fluxo Básico
1. Código novo
2. Testes locais
3. Code review
4. Merge na main
5. Deploy
Dicas de Sobrevivência
Commits pequenos
Testes, testes e mais testes
Feature flags são seus amigos
Code review rápido
Conclusão
TBD é rápido, moderno e eficiente. Como uma festa bem organizada, todo mundo se diverte junto, mas seguindo algumas regras básicas para manter tudo funcionando!
Feature Branch Workflow
Imagine que cada nova funcionalidade é como uma nova cena do American Pie - precisa ser filmada separadamente antes de entrar no filme final!
📝 Pull Request: Adiciona Sistema de Login
✨ O que foi feito:
- Form de login responsivo
- Validação de campos
- Integração com API
- Testes unitários
🔍 Como testar:
1. Checkout na branch
2. npm install
3. npm run test
4. Teste manual do form
📸 Screenshots:
[imagens do antes/depois]
Resolução de Conflitos
Dicas de Sobrevivência
1. Mantenha as Features Pequenas
Grande Feature ❌
├── 2 semanas
├── 50 arquivos
└── Difícil review
Features Menores ✅
├── 2-3 dias
├── 5-10 arquivos
└── Review tranquilo
2. Review Checklist
Métricas de Sucesso
📊 Indicadores Saudáveis
Tempo de Branch ┌────────────┐
2-3 dias |██████░░░░░░| ✅
Tamanho do PR ┌────────────┐
200-400 linhas |████░░░░░░░░| ✅
Taxa de Aprovação ┌────────────┐
Primeira review |████████░░░░| ✅
Conclusão
Feature Branch Workflow é como dirigir na sua própria pista: você tem liberdade para desenvolver no seu ritmo, mas sempre seguindo as regras de trânsito para chegar seguro ao destino!
Gitflow Workflow
Se o Feature Branch é uma festa na casa do Stifler, o Gitflow é o baile de formatura - tem regras, tem estrutura, mas ainda é divertido!
✅ Estrutura clara e definida
✅ Ideal para releases planejadas
✅ Suporte a hotfixes
✅ Processos bem documentados
Desvantagens
❌ Mais complexo que feature branch
❌ Overhead para projetos pequenos
❌ Curva de aprendizado maior
❌ Pode ser "pesado" demais
Dicas de Implementação
1. Ferramentas de Suporte
2. Checklist de Release
📋 Release Checklist
1. [ ] Feature freeze
2. [ ] Criar branch release
3. [ ] Bump version
4. [ ] Testes de regressão
5. [ ] Documentação
6. [ ] Code freeze
7. [ ] Deploy staging
8. [ ] Merge em main
9. [ ] Tag version
10.[ ] Deploy prod
Conclusão
Gitflow é como um roteiro de filme bem planejado - tem pré-produção (develop), filmagem (features), edição (release) e até correções de última hora (hotfix). Quando bem executado, o resultado é um blockbuster!
Forking Workflow
Se o Feature Branch é uma festa na casa do Stifler e o Gitflow é o baile de formatura, o Forking Workflow é como organizar vários American Pie ao mesmo tempo - cada um tem sua própria versão, mas todos contribuem para a franquia!
O que é Fork?
Fluxo Básico
Estrutura do Workflow
1. Setup Inicial
# Fork via interface do GitHub/GitLab
# Clone do seu fork
git clone https://github.com/seu-usuario/projeto.git
# Adicionar upstream
git remote add upstream https://github.com/projeto-original/projeto.git
2. Mantendo Sincronizado
Ciclo de Desenvolvimento
1. Atualizando seu Fork
# Buscar mudanças do original
git fetch upstream
# Atualizar sua main
git checkout main
git merge upstream/main
2. Feature Development
Processo de Contribuição
1. Preparando o Pull Request
2. Fluxo de Review
Boas Práticas
1. Organização de Branches
origem/
├── main
└── feature/
├── nova-funcionalidade
└── bugfix-importante
seu-fork/
├── main
└── feature/
└── sua-contribuicao
🔄 Rotina de Manutenção
Daily:
- Sync com upstream
- Review PRs
- Responder issues
Weekly:
- Cleanup branches
- Update docs
- Check stale PRs
Conclusão
O Forking Workflow é como criar seu próprio American Pie enquanto contribui para a saga original - você tem liberdade criativa, mas precisa manter a essência que fez a franquia um sucesso!
Gerenciamento de Releases
Como diria o Stifler: "Uma release é como uma festa - precisa de planejamento, organização e saber a hora certa de lançar!"
Fundamentos de Release Management
1. Ciclo de Release
2. Tipos de Release
Versionamento Semântico
1. Estrutura
MAJOR.MINOR.PATCH
| | |
| | `-- Correções de bugs
| `-------- Novas funcionalidades
`-------------- Breaking changes
Como em American Pie, o timing é tudo! Uma release bem executada é como uma festa perfeita - todos se divertem e nada dá errado (ou pelo menos sabemos como lidar quando dá).
Estratégias de Hotfix
Como o Stifler diria: "Bugs em produção são como aquela festa que começa a dar errado - você precisa agir rápido e com precisão!"
Como o Stifler aprendeu: em emergências, mantenha a calma, siga o processo e aja rápido! Um bom processo de hotfix é como ter um extintor de incêndio sempre à mão - você torce para não precisar, mas quando precisa, salva a festa!
Comparando Workflows
Se os workflows fossem festas do American Pie, seria assim:
Trunk-Based: Festa informal na casa do Jim
Feature Branch: Festa na casa do Stifler
Gitflow: Baile de formatura
Fork: Festival com várias stages
Visão Geral
Comparação Detalhada
1. Complexidade vs Flexibilidade
2. Tabela Comparativa
Aspecto
Trunk-Based
Feature Branch
Gitflow
Fork
Complexidade
Baixa
Média
Alta
Alta
CI/CD
Excelente
Bom
Moderado
Variável
Review
Rápido
Bom
Detalhado
Comunitário
Releases
Contínuas
Flexíveis
Planejadas
Independentes
Time Size
Pequeno
Médio
Grande
Distribuído
Cenários de Uso
1. Por Tamanho de Projeto
2. Por Tipo de Entrega
📦 Release Strategy Match
Continuous Delivery
└── Trunk-Based Development
Regular Releases
├── Feature Branch
└── Gitflow
Community/Open Source
└── Fork
🎯 Decision Matrix
Small Team + Fast Delivery
└── Trunk-Based
Medium Team + Regular Releases
└── Feature Branch
Large Team + Structured Releases
└── Gitflow
Open Source + Community
└── Fork
Migração entre Workflows
1. Processo de Transição
2. Checklist de Migração
📋 Migration Checklist
1. [ ] Avaliar workflow atual
2. [ ] Definir novo workflow
3. [ ] Treinar equipe
4. [ ] Projeto piloto
5. [ ] Migração gradual
6. [ ] Documentação
7. [ ] Monitoramento
Como escolher entre as festas do American Pie, a escolha do workflow depende do seu "estilo de festa":
Lembre-se: não existe workflow perfeito, existe o workflow certo para seu contexto. Como diria o Stifler: "A melhor festa é aquela que funciona pro seu grupo!"
Migração de Workflow
Como mudar de festa sem estragar a diversão? Vamos aprender a migrar entre workflows de forma suave e segura!
Planejamento da Migração
1. Avaliação Inicial
2. Matriz de Impacto
📊 Impact Matrix
Alto Impacto/Alta Urgência
├── CI/CD Pipeline
└── Branch Strategy
Alto Impacto/Baixa Urgência
├── Code Review Process
└── Release Schedule
Baixo Impacto/Alta Urgência
├── Commit Standards
└── Documentation
Baixo Impacto/Baixa Urgência
├── Tool Updates
└── Optional Features
Estratégias de Migração
1. Big Bang vs Gradual
2. Abordagem Gradual
Plano de Migração
1. Fases do Processo
2. Checklist por Fase
📋 Migration Phases
Preparação:
├── Análise atual
├── Define objetivos
├── Planeja mudanças
└── Prepara docs
Piloto:
├── Seleciona time
├── Implementa teste
├── Coleta feedback
└── Ajusta plano
Expansão:
├── Treina times
├── Migra gradual
├── Monitora
└── Suporte
Consolidação:
├── Valida processo
├── Ajusta final
├── Documenta
└── Celebra
Como diria o Stifler: "As regras existem pra festa não virar bagunça!" Boas práticas são como as regras da festa - elas garantem que todo mundo se divirta sem criar problemas!
Automação de Workflow
Como diria o Stifler: "Por que fazer manual o que a máquina pode fazer por você?" Vamos explorar como automatizar nosso workflow!
name: CI Pipeline
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Build
run: make build
- name: Test
run: make test
- name: Lint
run: make lint
O controle de versão é fundamental para o desenvolvimento de software moderno. Aqui estão as práticas essenciais para manter seu código organizado e sua equipe produtiva.
🔄 Reescrita de Commits
Local (antes do push):
├── git commit --amend
├── git rebase -i
└── git reset
Remoto (com cuidado):
├── Squash merges
├── Rebase time
└── Force push (-f)
Gerenciamento de Branches
Fluxo de Desenvolvimento
Estrutura de Branches
Ciclo de Vida de uma Branch
Convenções de Nomenclatura
Code Review
Checklist
[ ] Código segue padrões
[ ] Testes adicionados/atualizados
[ ] Documentação atualizada
[ ] Performance considerada
[ ] Segurança verificada
Feedback Construtivo
Foco no código, não no desenvolvedor
Sugestões específicas
Explicações claras
Reconhecimento de boas práticas
Terminologia do Controle de Versão
Conceitos Fundamentais
Repository (Repositório)
Local onde o código é armazenado
Contém todo o histórico do projeto
Pode ser local ou remoto
Inclui metadados e configurações
Branch (Ramo)
Linha independente de desenvolvimento
Permite trabalho paralelo
Isola mudanças em desenvolvimento
Facilita experimentações
Commit (Confirmação)
Snapshot do código em um momento
Inclui mensagem descritiva
Possui identificador único (hash)
Mantém autor e timestamp
Operações Básicas
Clone
Cria cópia local do repositório
Inclui todo histórico
Configura remote origin
Estabelece tracking branches
Pull
Atualiza repositório local
Combina fetch + merge
Sincroniza com remoto
Resolve conflitos se necessário
Push
Envia commits locais
Atualiza repositório remoto
Requer permissões
Pode exigir resolução de conflitos
Operações Avançadas
Merge (Mesclagem)
Combina mudanças de diferentes branches
Pode gerar conflitos
Mantém histórico de ambas as branches
Cria commit de merge
Rebase (Rebase)
Reaplica commits sobre outra base
Mantém histórico linear
Útil para manter branches atualizadas
Altera histórico de commits
Cherry-pick
Aplica commits específicos
Seletivo e preciso
Útil para hotfixes
Cria novos commits
Estados de Arquivos
Tracked (Rastreado)
Modified (Modificado)
Arquivo alterado
Não preparado para commit
Detectado pelo git status
Staged (Preparado)
Marcado para commit
Na área de staging
Pronto para confirmação
Committed (Confirmado)
Salvo no repositório
Parte do histórico
Possui hash único
Untracked (Não Rastreado)
Arquivos novos
Não incluídos no controle de versão
Precisam ser adicionados explicitamente
Ignorados via .gitignore
Glossário Expandido
Termo
Definição
Uso Comum
Clone
Cópia completa do repositório
Início do trabalho
Fork
Cópia independente do repositório
Contribuição externa
Pull Request
Solicitação para integrar mudanças
Colaboração
Tag
Marco específico no histórico
Releases
Hook
Script automatizado em eventos
Automação
Remote
Repositório em servidor
Colaboração
Head
Ponteiro para commit atual
Referência
Index
Área de staging
Preparação
Stash
Armazenamento temporário
Mudança de contexto
Fetch
Download de mudanças
Atualização
Configurações e Metadados
Arquivos de Configuração
.git/
├── config
├── HEAD
├── index
├── objects/
└── refs/
Agora você está pronto para começar a usar o Git. Continue para Primeiros Passos (Primeiros Passos).
História do Git
The simpsons homer
Para começar a historia do Git é até bem curta e direta. A comunidade do Linux usava um VCS distribuído chamado BitKeeper só que ele é proprietário.
Sim, um sistema open source usando um proprietário. Claramente isso era algo que causava um estranhamento na comunidade.
Stifler kiss
Que por sua vez chegou ao ápice quando o BitKeeper se tornou pago, logo a comunidade do Linux ficou alerta já que eles teriam que fazer o versionamento do núcleo do Linux em outro sistema.
Assim então a comunidade começou a criar seu próprio VCS que fosse:
Simples
Veloz
Não linear, ou seja, que aceite vários ramos (branches) de modificação
Capaz de lidar com grandes projetos, afinal, Linux é gigante
E assim nasceu o Git, exatamente em 2005 e até hoje está em evolução sendo um dos VCS mais utilizados em todo o mundo de desenvolvimento de gambiarras (softwares).
Linus Torvalds: "Eu sou um bastardo egoísta, e nomeio todos os meus projetos com meu nome. Primeiro Linux, agora Git"
(Git em gíria britânica significa "pessoa desagradável")
Recordes
Maior repositório Git: Android Open Source Project (>100GB)
Commit mais antigo ainda ativo: Kernel Linux (2005)
Maior plataforma: GitHub (200M+ repositórios)
Easter Eggs
git help --all # Lista todos os comandos, incluindo alguns divertidos
git help everyday # Guia de uso diário
git help tutorial # Tutorial básico
Conceitos Básicos do Git
Como o Git Funciona
O Git funciona de forma diferente de outros VCS. Em um outro VCS ele terá os arquivos e quando houver alteração eles criam uma lista somente das alterações.
Em um outro VCS ele terá os arquivos e quando houver alteração eles criam uma lista somente das alterações:
Version control system basico outros vcs
Agora com o Git ele faz diferente, já que vai tirando snapshots que são como fotos quando ocorre uma mudança e caso tenha algum arquivo que não foi alterado será guardado uma referencia para ele, assim pode ser recuperado.
Estrutura de Diretórios
Assim temos três níveis principais:
Diretório de trabalho (Working Directory)
Área de preparo (Staging Area)
Diretório .git que vai ser o repositório ou banco de dados local
Version control system fluxodetrabalho
Diretórios quando se trabalha com Git
Working Directory
É onde você realmente trabalha com seus arquivos. Aqui você pode:
Criar novos arquivos
Modificar arquivos existentes
Deletar arquivos
Staging Area
Também conhecida como "Index", é uma área intermediária onde você prepara as mudanças que farão parte do próximo commit.
Repositório Local (.git)
O coração do Git, onde todo o histórico do projeto é armazenado:
Dica Pro: Mantenha um cheat sheet personalizado com seus comandos mais usados!
Comandos Essenciais do Git
Comandos por Situação
💩 Socorro! Fiz Besteira!
# Ops, commitei na branch errada
git reset HEAD~1 # Desfaz o último commit mantendo as alterações
git checkout branch-correta # Muda para a branch correta
git add . # Adiciona as alterações
git commit -m "feat: ..." # Commit na branch certa
# Ops, commitei algo errado
git reset --soft HEAD~1 # Desfaz o commit mantendo alterações em stage
git reset --hard HEAD~1 # Desfaz o commit E as alterações (cuidado!)
# Ops, modifiquei o arquivo errado
git checkout -- arquivo.txt # Desfaz alterações não commitadas
# Ops, dei push em algo errado
git revert HEAD # Cria novo commit desfazendo alterações
git push origin main # Envia a reversão para o remoto
🆕 Começando um Projeto
# Iniciando do zero
git init
git add .
git commit -m "feat: commit inicial"
# Clonando projeto existente
git clone https://github.com/user/repo.git
git clone https://github.com/user/repo.git minha-pasta
# Status e logs
git status # Estado atual
git log # Histórico de commits
git log --oneline # Histórico resumido
git blame arquivo.txt # Quem alterou cada linha
# Diferenças
git diff # Alterações não staged
git diff --staged # Alterações staged
git diff branch1..branch2 # Entre branches
🤝 Merge e Rebase
# Merge
git checkout main # Vai para branch destino
git merge feature # Merge da feature
# Rebase
git checkout feature # Vai para branch origem
git rebase main # Rebase na main
# Conflitos
git merge --abort # Cancela merge
git rebase --abort # Cancela rebase
📌 Tags
# Criação
git tag v1.0.0 # Tag leve
git tag -a v1.0.0 -m "Release 1.0.0" # Tag anotada
# Publicação
git push origin v1.0.0 # Envia tag específica
git push origin --tags # Envia todas as tags
📦 Stash
# Guardando alterações
git stash # Guarda alterações
git stash save "WIP:..." # Guarda com descrição
git stash pop # Recupera e remove
git stash apply # Recupera e mantém
git stash list # Lista stashes
git stash drop # Remove stash
🎓 Comandos Avançados
Reescrevendo História
# Alterando commits
git commit --amend # Altera último commit
git rebase -i HEAD~3 # Rebase interativo
git cherry-pick <commit-hash> # Copia commit específico
# Limpeza
git clean -n # Lista arquivos a serem removidos
git clean -df # Remove arquivos não rastreados
# Encontrando bugs
git bisect start
git bisect bad # Marca commit atual como ruim
git bisect good <commit-hash> # Marca commit como bom
git bisect reset # Finaliza busca
git commit -m "feat: adiciona busca por localização"
git commit -m "fix: corrige bug no filtro de idade"
git commit -m "docs: atualiza README"
git commit -m "style: formata código"
git commit -m "refactor: simplifica função de busca"
Workflow Seguro
# Antes de começar
git pull origin main
git checkout -b feature
# Antes de commitar
git diff
git status
git add .
git commit -m "feat: ..."
# Antes de push
git pull --rebase origin main
git push origin feature
Dica Pro: Mantenha esse cheat sheet sempre à mão. Com o tempo você vai decorar os comandos mais usados, mas é sempre bom ter onde consultar!
# Listar referências
git show-ref
# Ver para onde HEAD aponta
git symbolic-ref HEAD
# Criar branch
git update-ref refs/heads/nova-branch HEAD
# Criar tag
git update-ref refs/tags/v1.0 HEAD
Referências Especiais
1. FETCH_HEAD
+------------------+
| FETCH_HEAD |
+------------------+
| Último fetch |
| de cada branch |
+------------------+
2. ORIG_HEAD
+------------------+
| ORIG_HEAD |
+------------------+
| Backup antes de |
| operações |
| perigosas |
+------------------+
# Hook de qualidade de código
#!/bin/sh
./lint.sh
./test.sh
# Hook de mensagem de commit
#!/bin/sh
commit_msg=$(cat "$1")
if ! echo "$commit_msg" | grep -qE "^(feat|fix|docs|style|refactor|test|chore):"; then
echo "Erro: Mensagem não segue convenção"
exit 1
fi
# Resolver detached HEAD
cd submodule
git checkout main
cd ..
git add submodule
git commit
# Forçar update
git submodule update --force --recursive
Workflows
Desenvolvimento
CI/CD
# Script de CI
#!/bin/sh
# Inicializar e atualizar submodules
git submodule update --init --recursive
# Build e teste
for module in $(git submodule | awk '{print $2}'); do
cd $module
npm install
npm test
cd ..
done
#!/bin/sh
# Script de atualização
for subtree in lib/*; do
if [ -d "$subtree" ]; then
prefix="lib/$(basename $subtree)"
remote="https://github.com/user/$(basename $subtree)"
git subtree pull --prefix=$prefix $remote main --squash
fi
done
Dica Pro: Use --squash ao adicionar subtrees para manter o histórico limpo, mas considere omiti-lo se precisar manter o histórico completo para referência.
Git Worktrees: Trabalhando com Múltiplos Diretórios
# Iniciar bisect
git bisect start
git bisect bad HEAD
git bisect good v1.0.0
# Marcar commits
git bisect good
git bisect bad
# Finalizar
git bisect reset
Automação
# Criar script de teste
echo '#!/bin/sh
make test' > test.sh
chmod +x test.sh
# Executar bisect automático
git bisect start
git bisect bad HEAD
git bisect good v1.0.0
git bisect run ./test.sh
# Script de teste completo
cat << 'EOF' > test.sh
#!/bin/sh
make build
if ! make test; then
exit 1
fi
if ! ./performance_test.sh; then
exit 1
fi
exit 0
EOF
Troubleshooting
Problemas Comuns
Soluções
# Salvar trabalho atual
git stash
# Limpar ambiente
git clean -fdx
# Restaurar estado
git bisect reset
git stash pop
Workflows Avançados
CI Integration
#!/bin/sh
# Script para CI
git bisect start HEAD v1.0.0
git bisect run docker-compose run tests
Dica Pro: Sempre teste filter-branch em um clone do repositório antes de aplicar no repositório principal. Mudanças são permanentes e podem ser difíceis de reverter.
O cherry-pick é como um rebase para um único commit. Ele pega as alterações introduzidas em um commit específico e as aplica na branch atual, criando um novo commit com o mesmo conteúdo, mas com um hash diferente.
Sintaxe Básica
# Formato básico
git cherry-pick <commit-hash>
# Exemplo prático
git cherry-pick abc123
# Cherry-pick múltiplos commits
git cherry-pick abc123 def456
# Cherry-pick de um range
git cherry-pick abc123^..def456
Técnicas Avançadas
Cherry-pick com Opções
# Cherry-pick sem commit automático
git cherry-pick --no-commit abc123
# Cherry-pick mantendo autoria original
git cherry-pick -x abc123
# Cherry-pick com mensagem personalizada
git cherry-pick -e abc123
# Cherry-pick apenas registrando (sem alterações)
git cherry-pick --signoff abc123
Resolvendo Conflitos
# Quando ocorrer conflito
git cherry-pick abc123
# ... conflito ocorre ...
# Resolver conflitos manualmente
# Depois:
git add .
git cherry-pick --continue
# Ou abortar o processo
git cherry-pick --abort
Casos de Uso
Backport de Correções
# Backport de uma correção
git checkout release/1.0
git cherry-pick abc123 # commit da correção
git tag v1.0.1
git push origin v1.0.1
Seleção de Features
+------------------------+
| CASOS DE USO |
| |
| • Backport de fixes |
| • Seleção de features |
| • Recuperação parcial |
| • Migração seletiva |
| • Testes isolados |
+------------------------+
Estratégias e Padrões
Cherry-pick vs Merge vs Rebase
Workflow com Cherry-pick
Boas Práticas
Quando Usar
✅ USE QUANDO:
• Precisa de commits específicos
• Backport de correções
• Migração seletiva
• Testes isolados
❌ EVITE QUANDO:
• Precisa de toda a branch
• Muitos commits sequenciais
• Histórico é importante
• Commits interdependentes
Dicas de Produtividade
# Alias útil para cherry-pick
git config --global alias.cp 'cherry-pick'
# Cherry-pick com mensagem personalizada
git cp -e abc123
# Cherry-pick múltiplos commits
git cp --no-commit abc123 def456 ghi789
git commit -m "Aplica features X, Y e Z"
Troubleshooting
Problemas Comuns
Soluções
# Conflito complexo
git cherry-pick --abort
git checkout -b temp-branch
git merge feature-branch
# Resolver manualmente
git checkout main
git cherry-pick temp-branch
# Verificar diferenças antes
git show abc123
Automação
Scripts Úteis
#!/bin/bash
# Cherry-pick todos os commits de uma branch que contêm uma palavra-chave
cherry_pick_by_keyword() {
local branch="$1"
local keyword="$2"
git log --grep="$keyword" --format="%H" "$branch" |
tac |
xargs -I{} git cherry-pick {}
}
# Uso: cherry_pick_by_keyword feature/login "auth"
Dica Pro: O cherry-pick é uma ferramenta poderosa, mas use com moderação. Commits frequentemente cherry-picked podem indicar problemas no seu workflow de branches.
Git Testing: Garantindo Qualidade no Versionamento
#!/bin/bash
# Script de automação de workflow
automate_workflow() {
# Update branches
git fetch --all
git pull origin main
# Clean old branches
git branch --merged | grep -v "\*" | xargs -n 1 git branch -d
# Run tests
./run_tests.sh
# Update dependencies
npm update
}
Batch Operations
def batch_operations():
"""
Operações em lote no Git
"""
repos = get_all_repos()
for repo in repos:
with cd(repo):
update_dependencies()
run_tests()
create_backup()
Git Hooks
Pre-commit Hook
#!/bin/bash
# .git/hooks/pre-commit
set -e
echo "🔍 Verificando código..."
npm run lint
echo "🧪 Executando testes..."
npm test
echo "📦 Verificando build..."
npm run build
Post-commit Hook
#!/bin/bash
# .git/hooks/post-commit
set -e
# Notify team
./notify_team.sh
# Update documentation
./update_docs.sh
# Run deployment if on main
if [[ $(git branch --show-current) == "main" ]]; then
./deploy.sh
fi
#!/bin/bash
# Debug automation
set -x
export DEBUG=true
run_automation() {
echo "Starting automation..."
./automate_workflow.sh 2>&1 | tee automation.log
}
Recovery
#!/bin/bash
# Recovery script
recover_automation() {
# Backup current state
git stash
# Reset to last known good state
git reset --hard last_good_commit
# Retry automation
./automate_workflow.sh
}
# Template de Página
{code:title=Exemplo|language=java}
public class Example {
// Código aqui
}
{code}
{status:colour=Green|title=Build Status}
Passed
{status}
Code Snippets
# Macro de código
{bitbucket:repo=project/repo|file=src/main.js|lines=10-20}
Dica Pro: Mantenha um plano de recuperação documentado e testado regularmente para minimizar tempo de recuperação em emergências.
GitLab: Visão Geral
+------------------------+
| GitLab |
| |
| DevOps Completo |
| Ciclo de Vida |
| Colaboração |
| |
| Tudo em Um |
+------------------------+
O que é GitLab?
O GitLab é uma plataforma DevOps completa, entregue como uma única aplicação. Ele abrange todo o ciclo de vida DevOps, permitindo que equipes colaborem, desenvolvam, testem, implantem e monitorem aplicações em um único ambiente.
Dica Pro: O GitLab oferece uma experiência DevOps completa, mas comece com os recursos básicos e vá expandindo conforme sua equipe se familiariza com a plataforma.
Embora o GitLab.com ofereça uma solução hospedada pronta para uso, existem várias razões convincentes para optar por uma instalação self-hosted:
Vantagens do Self-Hosted
Casos de Uso Específicos
Requisitos de Compliance: Organizações em setores regulamentados (finanças, saúde, governo) precisam manter dados sensíveis em suas próprias infraestruturas.
Ambientes Air-Gapped: Redes isoladas sem acesso à internet exigem soluções locais.
Personalização Avançada: Necessidade de integração profunda com sistemas internos e fluxos de trabalho específicos.
Performance: Controle sobre recursos de hardware para otimizar desempenho em grandes instalações.
Latência Reduzida: Instalação próxima aos desenvolvedores para operações Git mais rápidas.
+------------------------+
| QUANDO ESCOLHER |
| |
| • Dados sensíveis |
| • Muitos usuários |
| • Integração interna |
| • Controle total |
| • Compliance |
| • Redes isoladas |
+------------------------+
Dica Pro: Para ambientes de produção, sempre dimensione os recursos de acordo com o número de usuários e repositórios esperados. O GitLab pode consumir muitos recursos em instalações maiores.
O arquivo principal de configuração do GitLab é o /etc/gitlab/gitlab.rb para instalações Omnibus. Todas as configurações são centralizadas neste arquivo.
Dica Pro: Mantenha um ambiente de teste para validar alterações de configuração antes de aplicá-las em produção. Sempre faça backup antes de grandes mudanças.
O SSH (Secure Shell) permite que você se conecte e autentique em servidores remotos, como o GitLab, de forma segura sem precisar digitar sua senha a cada operação.
### Feedback Template
**Contexto**
- Arquivo/função em questão
**Observação**
- Descrição clara do ponto
**Sugestão**
- Proposta de melhoria
**Exemplo**
```código sugerido```
Um monorepo é um repositório único que contém múltiplos projetos relacionados, com possíveis diferentes linguagens de programação, ferramentas e releases independentes.
# Encontrar bug
git bisect start
git bisect bad
git bisect good <commit>
Contribuindo para o Git Pie 🤝
Antes de Começar
Antes de fazer uma contribuição, certifique-se de:
Verificar se já não existe uma Issue similar
Ler nosso Código de Conduta
Entender nossas diretrizes de contribuição
Como Contribuir
1. Preparando o Ambiente
# Clone o repositório
git clone https://github.com/seu-usuario/git-pie.git
# Entre no diretório
cd git-pie
# Instale as dependências
npm install
2. Criando uma Nova Feature
# Crie uma nova branch
git checkout -b feature/nova-funcionalidade
# Faça suas alterações
# ...
# Commit das mudanças
git commit -m "feat: adiciona nova funcionalidade"
# Push para seu fork
git push origin feature/nova-funcionalidade
3. Submetendo Alterações
Tipos de Contribuição
1. Documentação 📚
Correções de texto
Melhorias na explicação
Novos exemplos
Traduções
2. Código 💻
Novos recursos
Correções de bugs
Melhorias de performance
Testes
3. Design 🎨
Melhorias no layout
Novos diagramas
Imagens e ilustrações
Temas e estilos
Diretrizes
Commits
Seguimos o padrão Conventional Commits:
feat: nova funcionalidade
fix: correção de bug
docs: atualização de documentação
style: formatação de código
refactor: refatoração de código
test: adição/modificação de testes
chore: alterações em arquivos de build
Pull Requests
Seu PR deve incluir:
Descrição clara das mudanças
Screenshots (se aplicável)
Referência a Issues relacionadas
Checklist de alterações
Código
Siga o estilo de código do projeto
Adicione testes quando necessário
Mantenha a documentação atualizada
Evite alterações não relacionadas
Processo de Review
Verificação automatizada
Review por mantenedores
Feedback e ajustes
Aprovação e merge
Reconhecimento
Todos os contribuidores são reconhecidos em nosso arquivo CONTRIBUTORS.md e na documentação do projeto.
Precisa de Ajuda?
Abra uma Issue
Entre em contato com os mantenedores
Participe de nossas discussões
Próximos Passos: Veja nossa para encontrar algo para trabalhar.